NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/226

Text File | 1996-08-06 | 5.0 KB | 121 lines

Path: newshost.lanl.gov!tanmoy
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
Date: 30 Jan 1996 01:30:41 GMT
Organization: Los Alamos National Laboratory
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
    <4edqh2$[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: qcd.lanl.gov
Mime-Version: 1.0
Content-Type: text
In-reply-to: [e-mail]'s message of 29 Jan 1996 19:13:12 GMT

In article <[e-mail]>
[e-mail] (James Kanze US/ESC 60/3/141 #40763) writes:
<snip>
   I agree, but...

   Try naming a global function read, and see what happens (on most
   compilers, anyway).  In fact, the Posix standard requires it, and

What should happen? It compiles perfectly and produces the expected
answer!

tanmoy@qcd:tsh21540:48.0>>cat j.c
#include <stdio.h>
int read(int x) { return x + 1; }
int main(void) {
  return !printf("%d\n",read(1));
}
tanmoy@qcd:tsh21540:49.0>>glintc j.c
tanmoy@qcd:tsh21540:50.0>>a.out
2
tanmoy@qcd:tsh21540:51.0>>uname -a
SunOS qcd 4.1.4 2 sun4m

and also

tanmoy@qcd:tsh21540:59.0>>cat k.c
#include <stdio.h>
int read(x) { return x + 1; }
int main() {
  return !printf("%d\n",read(1));
}
tanmoy@qcd:tsh21540:60.0>>cc k.c
tanmoy@qcd:tsh21540:61.0>>a.out
2

(By the way, your assertion is correct: in general few compilers are
completely conforming. My examples don't work if I change read to a
write :-)

   thus, you cannot be Posix compliant without encroaching upon the user
   name space.  (For example.  I'm sure that most other systems will have
   similar constraints.)

This is incorrect. What the compiler has to do is to ensure that posix
definitions are not seen unless I invoke undefined behaviour (e.g. by
#including a posix specific header or leaving an external symbol
undefined). Pretty easy to arrange usually (if the linker helps by not
loading from the library something that has already been satisfied,
for example, and no library routine calls a routine in user name
space: if necessary they call a routine which is, separately, wrapped
by a name in the user space): but old machines (like SunOS) have not
yet done this.

   |> For example, assuming that the concept of a far pointer is truly
   |> required (It is really an exceptional circumstance which truly
   |> _requires_ it; a compiler should usually figure out whether a near or
   |> far pointer will work better: but that is a separate discussion), a
   |> compiler should invent a keyword in the implementation name space
   |> (e.g. __far) for it. It may provide a non-default switch
   |> /backward-compatible to allow it to recognize far as a keyword and
   |> treat it as a syntax error if used as a variable name.

   |> But I agree that discussions in comp.lang.c should also take care of
   |> current realities, even if those realities are fossils of an era long
   |> past, frozen in time only by the arrogant ignorance of a large body of
   |> users with a narrow view to the future.

   Well, I'm not sure that I'd consider Posix a fossil of an era long
   past, although it certainly reflects a long history.

As I said, almost no Posix extension requires diagnostic. It usually
specifies meaning for constructs undefined in C.

   I'm not sure where to draw the line.  Discussions of `read' certainly
   don't belong in c.l.c.  But simply telling someone that his system is
   broken because printf stopped working when he declared a global read
   is not going to help anyone, even if, strictly speaking, it is true
   according to the standard.

   I may be oversensitivized to this problem.  My usual hang-outs are the
   C++ groups.  Given the speed the C++ standard has evolved, there is no
   such thing as a conforming compiler, and most people have to get their
   programs working now, and not in 10 years time.  As a result, we do
   spend a lot of time talking about compiler idiocyncracies.

As far as comp.lang.c is concerned, I would say that pointing out to
people that their compiler is broken because it does not allow them an
external function called write is good enough. It tells them:
 1) The compiler should: they should complain to the vendor.
 2) The temporary fix is to not name the function write.

Isn't that good enough?

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]